El dominio es el núcleo de la aplicación en la arquitectura hexagonal. Aquí se definen las reglas de negocio puras sin depender de frameworks ni infraestructura.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Define un avión con atributos como modelo, capacidad y estado, encapsulando su comportamiento.
📜 Justificación:
✅ Encapsulación → Mantiene datos y lógica juntos.
🔹 Si no se tiene en cuenta: La lógica de negocio se dispersaría, afectando el mantenimiento.
✅ Independencia → No depende de infraestructura.
🔹 Si no se tiene en cuenta: Cambios en la base de datos podrían afectar directamente el dominio.
✅ Reutilización → Puede usarse en distintos contextos.
🔹 Si no se tiene en cuenta: Se tendría que redefinir la entidad en múltiples lugares, aumentando la duplicación.
.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Forma parte del núcleo del dominio en la arquitectura hexagonal.
✅ No depende de infraestructura ni frameworks, garantizando flexibilidad.
✅ En microservicios, permite la separación clara de responsabilidades.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Interfaz que define operaciones de acceso a datos.
📜 Justificación:
✅ Abstracción → Separa lógica de negocio de la persistencia.
🔹 Si no se tiene en cuenta: La lógica de negocio dependería directamente de la base de datos, dificultando cambios y pruebas.
✅ Flexibilidad → Se puede cambiar la implementación sin modificar el dominio.
🔹 Si no se tiene en cuenta: Cambiar de MySQL a MongoDB implicaría modificar todo el código del dominio.
✅ Inversión de dependencias → El dominio define qué necesita, sin conocer detalles de infraestructura.
🔹 Si no se tiene en cuenta: La capa de dominio quedaría acoplada a la base de datos, rompiendo principios de arquitectura hexagonal.
.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un puerto de salida, permitiendo cambiar la implementación sin afectar el dominio.
✅ Permite que la persistencia sea un detalle de infraestructura desacoplado del negocio.
✅ Facilita pruebas unitarias al poder inyectar implementaciones simuladas.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Gestiona lógica de negocio que involucra múltiples entidades.
📜 Justificación:
✅ Evita lógica en el controlador → Mantiene separación de responsabilidades.
🔹 Si no se tiene en cuenta: Los controladores se llenarían de lógica, volviéndose difíciles de mantener.
✅ Centraliza reglas de negocio → Evita duplicación de lógica.
🔹 Si no se tiene en cuenta: La misma lógica podría repetirse en distintos lugares, dificultando cambios y aumentando errores.
✅ Independencia de infraestructura → No usa base de datos ni dependencias externas.
🔹 Si no se tiene en cuenta: Sería difícil probar la lógica sin una base de datos real, afectando la escalabilidad y mantenibilidad.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un servicio puro del dominio, manteniéndose independiente de infraestructura.
✅ Facilita la modularización, permitiendo reutilizar la lógica en diferentes casos de uso.
✅ En microservicios, permite migrar lógica fácilmente entre servicios.
Orquesta los casos de uso, sin implementar lógica de dominio ni detalles de infraestructura.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Define el proceso de registro de un avión, utilizando servicios de dominio y repositorios.
📜 Justificación:
✅ Separa lógica de negocio de la API → Permite reutilización y facilita cambios.
🔹 Si no se tiene en cuenta: Cualquier cambio en el flujo del negocio obligaría a modificar los controladores.
✅ Facilita pruebas unitarias → No depende de infraestructura.
🔹 Si no se tiene en cuenta: Se necesitaría siempre una base de datos o un entorno completo para realizar pruebas.
✅ Cumple con la arquitectura hexagonal → Se conecta con puertos de entrada y salida sin acoplamiento.
🔹 Si no se tiene en cuenta: La lógica quedaría acoplada a detalles técnicos como HTTP o la base de datos.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un puerto de entrada, permitiendo diferentes maneras de ejecutar la lógica.
✅ Desacopla la lógica de negocio de la exposición (REST, eventos, etc.).
✅ En microservicios, facilita la reutilización de lógica en distintas interfaces.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Objeto de transferencia de datos entre capas.
📜 Justificación:
✅ Evita exponer el modelo interno → Protege la estructura del dominio.
🔹 Si no se tiene en cuenta: Cambios en la base de datos podrían afectar las respuestas de la API, rompiendo clientes externos.
✅ Permite controlar qué datos se exponen → Mejora seguridad y control.
🔹 Si no se tiene en cuenta: Datos sensibles podrían filtrarse en respuestas de la API.
✅ Optimiza la comunicación entre sistemas → Reduce la cantidad de datos transmitidos.
🔹 Si no se tiene en cuenta: Se enviaría información innecesaria, afectando el rendimiento.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Actúa como un contrato de datos, evitando acoplar clientes al dominio.
✅ Facilita compatibilidad entre microservicios, reduciendo cambios en el contrato.
✅ Optimiza la serialización y la transferencia de datos.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Convierte entre Avion y AvionDTO.
📜 Justificación:
✅ Mantiene el desacoplamiento entre API y dominio.
🔹 Si no se tiene en cuenta: Los controladores manejarían conversiones manualmente, aumentando la complejidad.
✅ Permite cambios en el modelo sin afectar la API.
🔹 Si no se tiene en cuenta: Un cambio en la estructura de Avion obligaría a modificar todos los controladores.
✅ Facilita pruebas y mantenimiento.
🔹 Si no se tiene en cuenta: Sería difícil garantizar que los datos se transforman correctamente.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Transforma datos entre capas, siguiendo el principio de separación de responsabilidades.
✅ Minimiza cambios en la API cuando cambia el modelo interno.
✅ En microservicios, facilita la interoperabilidad entre sistemas.
Implementa adaptadores que conectan la aplicación con persistencia, eventos y APIs externas.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Implementa AvionRepository usando JPA.
📜 Justificación:
✅ Permite cambiar la base de datos sin afectar el dominio.
🔹 Si no se tiene en cuenta: Cualquier cambio en la base de datos obligaría a modificar toda la lógica de negocio.
✅ Maneja la persistencia de manera eficiente.
🔹 Si no se tiene en cuenta: Se tendría que escribir SQL manualmente en cada parte del código.
✅ Reduce código repetitivo al aprovechar JPA.
🔹 Si no se tiene en cuenta: Se tendría que escribir lógica de acceso a datos manualmente.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un adaptador de salida, implementando un puerto de la arquitectura hexagonal.
✅ Permite que microservicios usen diferentes bases de datos sin cambiar el código del dominio.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Gestiona la comunicación con servicios externos de vuelos.
📜 Justificación:
✅ Encapsula la integración con terceros.
🔹 Si no se tiene en cuenta: Cualquier cambio en la API externa obligaría a modificar múltiples partes del código.
✅ Permite cambiar de proveedor sin afectar la lógica interna.
🔹 Si no se tiene en cuenta: Si el proveedor cambia su API, toda la aplicación se rompería.
✅ Facilita pruebas y simulaciones de APIs externas.
🔹 Si no se tiene en cuenta: Sería difícil probar la aplicación sin una conexión real al servicio externo.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un puerto de salida, asegurando flexibilidad en la comunicación con terceros.
✅ Facilita la integración desacoplada entre microservicios.
Gestionan comunicación asincrónica entre componentes o microservicios.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Publica eventos a un sistema de mensajería.
📜 Justificación:
✅ Permite comunicación entre microservicios sin acoplamiento.
🔹 Si no se tiene en cuenta: Un microservicio tendría que llamar directamente a otro, generando dependencias innecesarias.
✅ Mejora la escalabilidad.
🔹 Si no se tiene en cuenta: La aplicación podría volverse lenta si cada solicitud requiere comunicación síncrona.
✅ Facilita arquitecturas event-driven.
🔹 Si no se tiene en cuenta: No se podrían construir sistemas reactivos eficientes.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un puerto de salida, desacoplando la lógica de la mensajería.
✅ Facilita arquitecturas event-driven en microservicios.
Expone la aplicación a clientes externos.
📌 Descripción:
📜 Justificación:
📌 Descripción:
Expone los endpoints de la API.
📜 Justificación:
✅ Separa la lógica de presentación de la lógica de negocio.
🔹 Si no se tiene en cuenta: Los controladores estarían llenos de lógica compleja, dificultando su mantenimiento.
✅ Facilita la integración con clientes externos.
🔹 Si no se tiene en cuenta: Los consumidores de la API tendrían problemas de compatibilidad con la aplicación.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Es un puerto de entrada, permitiendo diversas interfaces sin modificar el dominio.
📌 Descripción:
📜 Justificación:
✅ Desacoplamiento → Permite que servicios se comuniquen sin llamadas directas.
🔹 Si no se tiene en cuenta: Los microservicios estarían fuertemente acoplados, dificultando escalabilidad y mantenibilidad.
✅ Escalabilidad → Facilita procesamiento asíncrono y arquitectura reactiva.
🔹 Si no se tiene en cuenta: El sistema podría volverse lento si todas las operaciones fueran síncronas.
✅ Alta disponibilidad → Evita bloqueos al procesar eventos en segundo plano.
🔹 Si no se tiene en cuenta: Si un servicio falla, las solicitudes podrían perderse en lugar de ser procesadas más tarde.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Actúa como puerto de salida, permitiendo interacción con sistemas externos sin acoplarse directamente.
✅ En microservicios, habilita un modelo event-driven, donde los servicios reaccionan a eventos en lugar de depender de llamadas directas.
✅ Permite la integración con diferentes plataformas sin modificar el dominio.
📌 Descripción:
📜 Justificación:
✅ Consistencia eventual → Permite que otros sistemas procesen el evento sin impactar la operación principal.
🔹 Si no se tiene en cuenta: Todos los sistemas tendrían que actualizarse en la misma transacción, afectando el rendimiento.
✅ Facilita la trazabilidad → Permite registrar y auditar los cambios en el sistema.
🔹 Si no se tiene en cuenta: No habría un mecanismo claro para seguir la actividad de los aviones registrados.
✅ Reactividad → Otros servicios pueden reaccionar sin modificar el código base.
🔹 Si no se tiene en cuenta: Sería necesario modificar el código de cada servicio que necesita esta información, afectando la modularidad.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Representa un evento de dominio, clave en arquitecturas event-driven.
✅ En microservicios, facilita la comunicación asíncrona entre servicios, evitando dependencias directas.
✅ Puede ser publicado por EventPublisher y consumido por AvionEventListener.
📌 Descripción:
📜 Justificación:
✅ Desacoplamiento → Los servicios que reaccionan a eventos no dependen directamente del servicio que los genera.
🔹 Si no se tiene en cuenta: Sería necesario modificar el servicio principal cada vez que un nuevo proceso necesite reaccionar al evento.
✅ Escalabilidad → Permite que múltiples consumidores procesen eventos en paralelo.
🔹 Si no se tiene en cuenta: Todo el procesamiento recaería en un solo servicio, limitando el rendimiento.
✅ Flexibilidad → Permite añadir nuevas funcionalidades sin tocar la lógica central.
🔹 Si no se tiene en cuenta: Cada nueva funcionalidad tendría que implementarse dentro del servicio principal, reduciendo la modularidad.
🔷 Papel en la arquitectura hexagonal/microservicios:
✅ Actúa como adaptador de entrada, permitiendo que el sistema reaccione a eventos sin acoplamiento directo.
✅ En una arquitectura event-driven, facilita el procesamiento distribuido y asincrónico.
✅ Permite integrar nuevas funcionalidades sin modificar el servicio de registro de aviones.